Modernly, the use of PCs (personal computers), including so-called laptop and notebook computers, is increasingly common and the computers themselves are ever more powerful and complex. A persistent problem is the unduly long elapsed time between the moment of power-on and the time when the PC has become ready for user stimulus and/or to initiate useful work.
Intel® Corporation first defined EFI (Extensible Firmware Interface) as the programming interface exposed by firmware to O/S (operating system); former comparable firmwares were not sufficiently portable nor scalable to Intel's CPU (Central Processor Unit) IA64 architecture. A first implementation of the EFI interface became known as Tiano, which Intel® Corporation offered under license via a web site. The UEFI Forum (Unified EFI Forum), a trade group, secured architectural control over EFI (and derivatives thereof) under a new name—UEFI, with a right to support and extend. The UEFI Forum documents and specifies the UEFI interface.
The PIWG (Platform Initialization Working Group) of the UEFI Forum provides a common internal framework for Silicon and platform drivers, so that a common understanding of the roles and methods used by Silicon and platform drivers is developed by implementers of UEFI firmware stacks together with the providers of the Silicon and platform drivers.
The UEFI and related standards provide richness, but fail to sufficiently address significant specific areas of concern including:    Quality of board bring-up user experience    Quality of BIOS customization experience    Duration of system bootloading and platform initialization time    Level of reliability    Level of compatibility with Intel's Foundation Core (also known as Foundation for short and a part of Tiano)    Scope for platform innovation by BIOS (basic input-output system) vendors and partners and customers thereof.
These attributes are described in the current version of SCT (SecureCore Tiano™) System Overview published by Phoenix® Technologies Ltd. Adequately addressing all of these areas of concern requires innovation above and beyond what is described in UEFI and PIWG standards. However, innovation needs to be at least backwards compatible with those same standards so as not to lose benefits of compliance therewith.
The EFI/UEFI environments provide for DXE (Driver Execution Environment) firmware running in a limited execution environment with a fixed control policy. A sole means of communication between drivers is the so-called Protocol, a means for drivers to publish pointers to internal routines and data so that other drivers may call and exploit them. Drivers, also known as device drivers are well-known in the computing arts. Although running in protected mode, with 32-bit or 64-bit addressability, the DXE environment implements drivers as connected islands of functional capabilities.
This environment relies on dependency expressions of protocols exposed by DXE drivers, and upon a schedule of DXE drivers to be loaded in a desirable order. Once loaded, DXE drivers are run once, publishing protocols as necessary, so that they might be called again only when their services are requested through published protocols. Limited services are provided by the Foundation for a DXE Driver to gain control on a timer tick, as well as being notified when an O/S loads or has finished loading. Functionality is thereby limited, perhaps unduly limited in view of the specific areas of concern previously mentioned. UEFI lacks a structural framework for execution that is sufficiently flexibly adaptable to problems presented in practical embodiments.
However, UEFI Specification(s) offer considerable richness by making it possible to combine drivers together into stacks in many different ways to form new compound capabilities. In this way UEFI compliant products may contemplate taking on a large problem space for the future.
While UEFI's protocols are well-defined, the execution vehicles providing support for drivers that implement these protocols in the native EFI environment is relatively primitive. There exists a need to provide a more feature-rich extension of the Foundation that provides for various needs. Described elsewhere is support for more modern programming paradigms. The present invention addresses, inter alia, the need for support for the multiple processor modes found in modern CPUs (Central Processor Units). Early CPUs, such as conventional eight-bit microprocessors may have provided for only one or two modes (for example, user mode and supervisor or interrupts-disabled mode). Modernly many modes are available and a need exists to support them within the pre-boot environment (or during the bootloading process itself as drivers become dynamically loaded). Processor state may be reflected in programmed features such as processor contexts and process contexts. These may include, for example but not limited to, real, protected and paging memory accessing, direct, pass-through and virtualized I-O (input-output operations), System management modes (for example providing common memory addressing directed by NorthBridge chips across VMs (virtual machines)), STMs (system management interrupt transfer monitors), multiple CPU core operation including changes in the number of active cores, cache operational modes, clock speeds and so on.
A significant advantage of embodiments of the invention over previously developed solutions is that it becomes possible to use multiple processor, memory and other instruction-controlling modes, especially but not limited to hardware modes within and around any and all DXE phases of computer loading and initialization.